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Method and System for user attestation-signatures 

with attributes 



TECHNICAL FIELD 



The present invention is related to a method for generating and verifying a user attestation- 
5 signature value and issuing an attestation value for the generation of the user attestation- 
signature value. Further, the invention is related to a system for using the user attestation- 
signature value. Moreover, the invention is also related to a computer program element for 
performing the method and a computer program product stored on a computer usable medium 
for causing a computer to perform the methods. 



1 0 BACKGROUND OF THE INVENTION 

Computers have evolved to tools for many applications and services. In today's world a 
trustworthy computing environment becomes more and more a desire. Comprehensive trust, 
security, and privacy functions are required to establish multi-party trust between devices, 
upon which content providers, application and service providers, consumers, enterprises and 
15 financial institutions, and particularly users can rely. 

For that, a trusted platform module (TPM) has been established. The role of the module is to 
offer protected storage, platform authentication, protected cryptographic processes and 
attestable state capabilities to provide a level of trust for the computing platform. The 
foundation of this trust is the certification by a recognized authority that the platform can be 

20 trusted for an intended purpose. A so-called trusted computing group (TCG) develops and 
promotes open industry standard specifications for trusted computing hardware building 
blocks and software interfaces across multiple platforms, including PC's, servers, PDA's, and 
digital phones. This will enable more secure data storage, online business practices, and online 
commerce transactions while protecting privacy and individual rights. Users will have more 

25 secure local data storage and a lower risk of identity theft from both external software attack 
and physical theft. 
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To realize the functionality of attestable states, an issuer issues a certificate to the trusted 
platform module, hereafter also abbreviated as TPM, as to allow the TPM to later prove 
remotely that it is a genuine TPM and therefore a verifying party can have confidence stated 
and attested by the TPM. To allow the TPM to prove it is genuine without that the verifying 
5 party can identify the TPM, a so-called direct anonymous attestation (DAA) sing protocol has 
been specified by the trusted computing group. The protocol allows the TPM to convince a 
verifying party that it obtained attestation by an issuer without revealing its identity. 

Further, the TCG specified a DAA issue protocol to provide attestation (with a certificate) to a 
platform's TPM such that the platform can later prove to any party that it preserved attestation 
10 without that the verifying party can identify the platform or link this proof of attestation with 
other proofs of attestation that the platform provided. 

The direct anonymous attestation procedure however does not allow to include predicates or 
attributes that the platform can use or show to any verifier in an anonymous way when proving 
that it got attestation. 

15 From the above it follows that there is still a need in the art for an improved protocol and 
system that allow attestation with certified/attested attributes or attribute values which remain 
anonymous within the transactions. 

GLOSSARY 

20 The following are informal definitions to aid in the understanding of the description. 



attribute(s) - A, B, C, D with respective attribute values w, x, y, z 

x, y - attester hidden attribute value, or user determined attribute value 

w, z - attester revealed attribute value, attester determined attribute value, or 

25 anonymous attribute value 

w, y - verifier hidden attribute value 

x, z - verifier revealed attribute value, revealed attribute value, 
or non-anonymous attribute value 
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TPM - trusted platform module 

PKuc - user public key 

5 

PK A c - attester public key with values n,g,g',h,S,Z,Ro,Ri,r,y,/> 

PK'ac - modified attester public key 

SKac - attester secret key 

10 cert - attestation value 

cert' - user value 

DAA' - user attestation-signature value 

DAA - security module attestation value, or 

part of the user attestation-signature value 



15 



fo,fh v' - TPM secret values 



a - first part of attestation value cert, or first attestation value 

c, sfl), sfl, sv, sx, sy - proof values, with sx, sy being augmented proof values 

20 c - part of proof values 

c ' - second proof verification value 

C ' - second signature value, or intermediate user attestation-signature value 

Ch - intermediary proof value 

e - second part of attestation value cert, being a random prime 

25 G ' - first user attestation-signature verification value 

G, sfO \ sfl \sv' - part of security module attestation value DAA 

sy \ sw \ se \ seu '- part of user attestation-signature value DAA' 

Ti - part of user attestation-signature value DAA' 

30 Ti - first signature value, or first security module attestation value 

T '/ - intermediary user attestation-signature value 

T"'i - intermediary user attestation-signature verification value 
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U - part of public key of security module PKtpm 

U' - intermediary proof value 

U' ' - first proof verification value 

U" ' - intermediary certificate value 

5 

v - secret signature value, with v = v *+ v ' ' 

v " - third part of attestation value cert, being a random integer 

W - first intermediary user proof value 

\0 W - second intermediary user proof value 



SUMMARY AND ADVANTAGES OF THE INVENTION 

In the following are proposed a system and methods which allow attestation with 

15 certified/attested attributes or attribute values that remain anonymous within transactions. In 
general, the attestation can comprise predicates that can later be shown anonymously. That is, 
the attestation can comprise several properties or attributes of a platform or its user. The 
transactions are performed between a user's user computer having a trusted platform module, 
an attestor or attester computer, e.g., a privacy certification authority, and a verifier or 

20 verifying party, which typically is a verification computer. As indicated, the user device has a 
security module, herein also referred to as trusted platform module (TPM), and together 
referred to as platform, which allows platform authentication, protected cryptographic 
processes, and attestable state capabilities. When the TPM anonymously proves that it got 
attestation, each property or attribute can either be shown or hidden. For instance, for a 

25 platform having attestation could mean that it is a valid platform, e.g., laptop, PDA, mobile, 
etc., of some company. Then, the attributes could be used to encode a particular branch or site 
of the company. When proving that it had obtained attestation, the platform could be granted 
access to some resource, e.g., the company's LAN (via wireless access points or the public 
Internet). Using the properties/attributes, one could then for instance tell whether it f s a local 

30 user or a guest from another branch. 

The attributes or properties comprised in the attestation can be determined by the user, by the 
attestor, or by both of them together. 
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An alternative would be to store some properties/attributes of the platform in the TPM and 
then have the TPM to send them to the verifier signed with a temporal secret key, the public 
key of which the TPM signs with the anonymous attestation protocol. These 
properties/attributes could be written into the TPM during manufacturing and could not be 
5 changed afterwards. Clearly, this allows one only handle properties/attributes that are 
supported by the TPM and does not allow to change them, which is rather inflexible. In the 
proposed system and methods, however, the number and kind of property/attribute in not 
restrained by the TPM, the properties/attributes can be changed, and the properties/attributes 
can be certified by anyone, i.e., also by entities different from the manufacturer. 

10 Each property or attribute has a property or attribute value. In the following, only the term 
attribute and attribute value is used for simplicity. 

In accordance with the present invention, there is provided a system for using a user 
attestation-signature value DAA' that corresponds to at least one attribute (A, B, C, D) with an 
attribute value (w, x, y, z), none, one or more of the attribute values (x, y) remaining 

15 anonymous for and in transactions. The system comprises a user device having a security 
module that provides a module public key PK T pm and a security module attestation value 
DAA. The user device provides a user public key PKuc that inherently comprises a user 
determined attribute value (x, y) and a proof value demonstrating that the user public key 
PKuc is validly derived from the module public key PK TPM of the security module. The system 

20 further comprises an attester computer that provides an attester determined attribute value (w, 
z) and an attestation value cert that bases on an attester secret key SK A c, the user public key 
PKuc, and usually an attester determined attribute value (w, z). The system further comprises 
a verification computer for verifying whether or not (i) the user attestation-signature value 
DAA' was validly derived from the security module attestation value DAA provided by the 

25 security module and the attestation value cert, and (ii) the attestation value cert is associated 
with a subset (B, D) of at least one attribute, each attribute in the 5-ubset (B, D) having a 
revealed attribute value (x, z). 

In accordance with a further aspect of the present invention, there is provided a method for 
generating a user attestation-signature value DAA' for use with a verification computer, the 
30 user attestation-signature value DAA' corresponding to at least one attribute (A, B, C, D), 
each with an attribute value (w, x, y, z), none, one, or more of the attribute values (w, y) 
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remaining anonymous in transactions performable by a user device having a security module 
with the verification computer. The method comprises the steps of 

providing a user public key PKuc and a proof value that demonstrates that the user public key 
PK UC was validly derived from a module public key PK T pm of the security module; 

5 receiving from an attester computer 

(I) an attestation value cert having the at least one attribute (A, B, C, D) with its 
attribute value (w, x, y, z), none, one or more of the attribute values (x, y) remaining 
unknown to the attester computer, 

the attestation value cert being derived from an attester secret key SKac, a user 
10 public key PKuc, and none, one, or more attester determined attribute values (w, z), 

the user public key PKuc inherently comprising none, one, or more user 
determined attribute values x, y, and 

(II) at least one of the attester determined attribute values (w, z); and 

deriving the user attestation-signature value DAA' from the attestation value cert and a 
15 security module attestation value DAA provided by the security module, 

wherein it is verifiable whether or not (i) the user attestation-signature value DAA' was 
validly derived from the security module attestation value DAA and the attestation value cert, 
and that (ii) the attestation value cert is associated with a subset (B, D) of at least one 
attribute, each attribute in the subset (B, D) having a revealed attribute value (x, z). 

20 The step of deriving the user attestation-signature value DAA' can further comprise the steps 
of: receiving from the security module a first security module attestation value T'r, deriving an 
intermediate user attestation-signature value C from the first security module attestation value 
T'i under use of an attester public key PK A c and a hash function; providing the intermediate 
user attestation-signature value C to the security module; receiving from the security module 

25 a part of the user attestation-signature value DAA'; and calculating by the user device further 
parts of the user attestation-signature value DAA' using none, one, or more attribute values 
(w, y) encoded in the attestation value cert but which are not to be revealed to the verifier and 
therefore are also referred to as verifier hidden attribute values (w, y), the received part of the 
user attestation-signature value DAA', the user public key PKuc, and the attester public key 
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PK A c. This guarantees that these attribute values remains unknown to the verification 
computer. 

The user public key PKuc can be derived from the module public key PKtpm by using the 
attester public key PK A c and the one or more of the attribute values (x, y). By doing so, it is 
5 affirmed that these attester hidden attribute values (x, y) remains unknown to the attestor, i.e. 
the attester computer. 

The user device can provide encryptions under a trusted third party's public key of one or 
more of the verifier hidden attribute values (w, y), i.e. the user determined attribute values w 5 
y that remain unknown to the verification computer. This allows the trusted third party to later 
10 recover the verifier hidden attribute values (w, y). 

In accordance with a another aspect of the present invention, there is provided a method for 
issuing an attestation value cert for the generation of a user attestation-signature value DAA' 
corresponding to at least one attribute (A, B, C, D), each with an attribute value (w, x, y, z), 
none, one or more of the attribute values (w, y) remaining anonymous for transactions 

15 performable by a user device having a security module with an attester computer. The method 
comprises the steps of receiving from the user device a user public key PKuc that inherently 
comprises none, one, or more user determined attribute value (x, y) invisible to the attester 
computer and a proof value demonstrating that the user public key PKuc was validly derived 
from a module public key PK TPM of the security module; issuing the attestation value cert 

20 based on an attester secret key SK A c, the received user public key PKuc, and none, one, or 
more attester determined attribute value (w, z); and providing the attestation value cert to the 
user device, wherein the user attestation-signature value DAA' is derivable by the user device 
from the attestation value cert and a security module attestation value DAA provided by the 
security module, and it is verifiable whether or not (i) the user attestation-signature value 

25 DAA 5 was validly derived from the security module attestation value DAA and the attestation 
value cert and that (ii) the attestation value cert is associated with a subset (B, D) of at least 
one attribute, each attribute in the subset (B, D) having a revealed attribute value (x, z).. 

In accordance with a yet a further aspect of the present invention, there is provided a method 
for verifying a user attestation-signature value DAA' generated from an attestation value cert, 
30 the user attestation-signature value DAA' corresponding to at least one attribute (A, B, C, D), 
each with an attribute value (w, x, y, z), none, one, or more of the attribute values (w, y) 
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remaining anonymous for transactions performable by a user device having a security module 
with a verification computer. The method comprises the steps of receiving from the user 
device the user attestation-signature value DAA 5 ; and verifying whether or not (i) the user 
attestation-signature value DAA' was validly derived from a security module attestation value 

5 DAA provided by the security module and an attestation value cert, and (ii) the attestation 
value cert is associated with a subset (B, D) of at least one attribute, each attribute in the 
subset (B, D) having a revealed attribute value (x, z), the attestation value cert being derived 
from an attester secret key SK A c> a user public key PKuc, and an attester determined attribute 
value (w, z) that remains anonymous, the user public key PKuc inherently comprising a user 

10 determined attribute value (x, y), i.e. an attester hidden attribute value. 

The step of verifying can further comprise computing a first user attestation-signature 
verification value G' by using the user attestation-signature value DAA 5 , the attester public 
key PKac, and the revealed attribute value (x, z); and checking whether or not the first user 
attestation-signature verification value G' is comprised in the user attestation-signature value 
15 DAA'. 



DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the invention are described in detail below, by way of example 
only, with reference to the following schematic drawings. 



20 



FIG.l 



shows a schematic illustration of a scenario with an attester computer (AC), a 
user computer (UC) having a trusted platform module (TPM), and a 
verification computer (VC). 



FIG. 2 



shows a schematic flow between the trusted platform module (TPM), the user 
computer (UC), and the attester computer (AC). 



25 
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FIG. 3 shows a schematic flow for the generation and verification of a user attestation- 

signature value DAA' between the trusted platform module (TPM), the user 
computer (UC), and the verifier, i.e. the verification computer (VC). 

The drawings are provided for illustrative purposes only. 

5 

DETAILED DESCRIPTION OF EMBODIMENTS 

Before the embodiments of the invention are described with reference to the figures, some 
general issues to an attestation scheme are addressed. 

A direct anonymous attestation protocol involves an issuer or attestor, a trusted platform 
10 module (TPM), a host platform (host) with the TPM, and several verifiers. All communication 
of the TPM is performed via its host. The issuer or attestor issues an attestation to the host and 
the TPM together in such a way that 

- when proving that attestation has been obtained, the host can only do so when involving the 
TPM, 

15 - proving possession of an attestation can be done anonymously (or pseudonymously), i.e., 
such that no verifier can not link two different proofs (or proofs with different verifiers can 
not be linked). 

Thus, the attestation scheme comprises four procedures: 
20 a "key generation" that allows the issuer to generate the public and secret keys of the 
attestation scheme; 

a "join protocol" that is run between a host/TPM and the issuer and allows the host/TPM to 
obtain attestation; 

a "sign procedure" that is run between a host and the TPM that allows them to anonymously 
25 prove that they got attestation and at the same time authenticating a message, the result of this 
proof is a signature that can be sent to a verifier; and 

a "verify procedure" that allows a verifier to check whether or not a platform got attestation 
and whether this platform authenticated a given message. 
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The attestation can comprise several attributes, whereby each attribute can either be shown or 
hidden. The attributes can be determined by the user, by the attestor, or by both of them 
together. When proving that an attestation that comprises attributes has been obtained, a user 
can choose which attributes can be revealed to the verifier and which should not be revealed. 

The following figures and descriptions show how a user attestation-signature value can be 
applied. 



Fig. 1 shows a schematic illustration of a system with an attester computer 30, also labeled 
10 with AC, a user device 20 comprising a security module 22 which are labeled with UC and 

TPM, respectively, and a verification computer 40, labeled with VC. The user device 20 that 

represents the host platform (host) or short platform is connected to the attester computer 30, 

herein also referred to as issuer or attestor, and the verification computer 40, i.e., the verifier. 

The system allows to use a user attestation-signature value DAA' that corresponds to 
15 attributes A, B, C, D having an attribute value w, x, y, z. The system is designed such that 

verifier hidden attribute values w, y remain anonymous in transactions with the verification 

computer 40. 

Beside the verifier hidden attribute values w, y, which are also called anonymous attribute 
values, the attribute values are named as follows: 
20 x, y - attester hidden attribute values, or user determined attribute values as they are 
determined by the user; w, z - attester revealed attribute values, or attester determined attribute 
values as they are determined by the attestor, x, z - verifier revealed attribute values, revealed 
attribute values, or non-anonymous attribute values. 

The TPM, i.e., the security module 22, provides a module public key PK T pm while the user 
25 device 20 further provides a user public key PKuc that inherently comprises the user 
determined attribute value x, y and a proof value or values demonstrating that the user public 
key PKuc is validly derived from the module public key PK T pm of the security module 22. The 
security module 22 further provides a security module attestation value DAA that is a part of 
the user attestation-signature value DAA 5 . 
30 The attester computer 30 provides an attester public key PK A c and has an attester secret key 
SK A c- Moreover, the attester computer 30 provides the attester determined attribute values w, 
z and an attestation value cert that bases on the attester secret key SK A c> the user public key 
PKuc, and the attester determined attribute value w, z. 
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The verification computer 40 can verify whether or not (i) the user attestation-signature value 
DAA' was validly derived from the security module attestation value DAA provided by the 
security module 22 and the attestation value cert, and (ii) the attestation value cert is 
associated with a subset of the attributes B, D having the revealed attribute values x, z. 

5 

In operation, as indicated in the figure with arrow 1 and labeled with "PKuc, proof, the user 
device 20 sends to the attester computer 30 the user public key PKuc that inherently comprises 
the user determined attribute value x, y and the proof value or values. In return the attester 
computer 30 sends back the attestation value cert and the attester determined attribute value 
10 w, z., as indicated with arrow 2, labeled with "cert, AC attr. (w, z)". The user device 20 can 
then send the user attestation-signature value DAA' together with a subset of attributes 
comprising here the revealed or non-anonymous attribute values x, z, as indicated with arrow 
3 and labeled with "DAA 5 , subset (x, y)" to the verification computer 40 that then can initiate 
the verification procedure. 

15 

Fig. 2 shows a schematic flow between the trusted platform or security module 22, the user 
computer 20, and the attester computer 30 as it is indicated with the arrows 1 and 2 labeled 
with "PKuc, proof and "cert, AC attr. (w, z)", respectively, in Fig. 1. At first, in step 101 the 
security module 22 generates the module public key PK T pm and TPM secret values f 0 ,fi, v' 

20 from a modified attester public key PK'ac- The user device 20 uses the module public key 
PKtpm in step 102 together with the attester public key PK A cand the user determined attribute 
values x, y of the attributes B, C in order to generate the user public key PKuc that inherently 
comprises the user determined attribute values x, y and to generate the proof value or values, 
indicated with "proof, demonstrating that the user public key PKuc ; s validly derived from 

25 the module public key PKtpm of the security module 22. The proof comprises proof value c, 
s/0, sfl, sv, sx, sy as described in more detail below. The attester computer 30 generates then 
in step 103 with the "PKuc, proof, the attester secret key SK AC , and the attester determined 
attribute value w, z the attestation value cert. As indicated with arrow 2 in Fig. 1, the 
attestation value cert together with the attester determined attribute values w, z are then 

30 provided to the user computer 20 which in step 104 generates a user value cert\ This user 
value cert' is then used by the security module 22 in step 105 to generate a secret signature 
value v. 
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Fig. 3 shows a schematic flow for the generation and verification of the user attestation- 
signature value DAA' between the security module 22, i.e. the TPM, the user computer 20, 
also referred to as platform 20, and the attester computer 30 as it is indicated with arrow 3 
labeled with "DAA', subset (x, y)" in Fig. 1. In step 201 the security module 22 generates 
5 from the modified attester public key PK'ac, some of the TPM secret values fo.fu and the 
secret signature value v a first signature value T'\, also referred to as first security module 
attestation value. When the first signature value T\ is received by the platform 20 an 
intermediary user attestation-signature value T"j is computed or derived from the first 
signature value T'j. The platform 20 uses then the intermediary user attestation-signature 

10 value T"i in step 202 together with the attestation value cert, the attester public key PK A c and 
the verifier hidden attribute values w, y to generate with a hash function a second signature 
value C\ also referred to as intermediate user attestation-signature value. This second 
signature value C and the TPM secret values f 0 ,fu v' are used in step 203 by the security 
module 22 to generate a security module attestation value DAA. The platform 20 is then able 

15 to derive from the security module attestation value DAA in step 204 together with the 
attestation value cert, the attester public key PK A c, the user public key PKuc, and the verifier 
hidden attribute values w, y the user attestation-signature value DAA'. 

When the user computer 20 provides the user attestation-signature value DAA' to the 
20 verification computer 40, this verifier can then under use of the attester public key PK A c and 
the revealed attribute values x, z verify whether or not the user attestation-signature value 
DAA' was validly derived from the security module attestation value DAA and an attestation 
value cert, and further whether or not the attestation value cert is associated with a subset B, D 
of the attributes with the revealed attribute values x, z. As indicated with the output arrow 
25 from the verification step 205, it turns out either "OK" or "not OK ", i.e. either the verification 
is valid or not. 

More precisely, the public key of the attester computer 30, hereafter called attestor, normally 
comprising the values (n,g,g',h,S,Z,Ro,Ri,r, y,p) is augmented with base values fo...., Rk- 
30 Each of these base values /fc,...., Rk corresponds to a particular attribute A, B, C, D, e.g., A 
corresponds to R2, B corresponds to R 3 , C corresponds to R 4 , and D corresponds to R 5 . In the 
following only the base values R 2 ,....,R5 are used, however, it is straightforward, to generalize 
the description as to use any number of such values. 
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To obtain an attestation value cert from the attestor, the user computer 20, hereafter called 
platform, receives a value U from the security module 22, hereafter called TPM, and computes 

U = U-R 2 x -R 3 y mod n 
and sends this value to the attestor. The value U is also called part of the public key of security 
5 module PKtpm whilst the computed U* is also referred to and used as intermediary proof 
value. 

Here it is assumed that the platform keeps the first two attributes hidden from the attestor, 
however note that one could use any subset of attributes instead. Furthermore, the platform 
10 receives at least a first intermediary user proof value W from the TPM from which the 
platform computes the second intermediary user proof value 

W'= W-R 2 r2 -R 3 r3 , 

where r2 and r3 are randomly chosen integers. Note that the computation of W should 
correspond to the computations of U\ that is, each of the base values R t that appears in the 

15 computation of U' should appear in the computation of W with a random exponent rL The 
platform then uses W instead of W in the computation of an intermediary proof value Ch as 
input to the hash function and sends ch to the TPM. The TPM will respond with further proof 
values c, sJO, s/7, and sv. The platform augments these further proof values with values sx = r2 
+c • x and sy = ri +c • y and sends these augmented proof values to the attestor. The attestor 

20 verifies these proof values by computing a first proof verification value 

[/»= ye . sr . Rjf* . . r* . R 3 v mod* , 
using U" in the input to the hash function to derive a second proof verification value c' and 
verifying whether c' equals the value c contained in the augmented proof values. If these 
verification succeeds, the attestor computes an intermediary certificate value 

25 tf'"= tf'.tf/./?5 Z mod*, 

where w and z are the attester determined attribute values, chooses a random prime e of 
suitable size and a random integer v", and computes a first attestation value 

a = (Z/(U iy '-S v )) l/e mo& n. 
Similar to the attributes values determined by the platform, the attestor could chose different 

30 attribute values. If the attestor uses one base value Ri that was used also by the platform, then 
the corresponding attributes will be jointly determined by the platform and the attestor. This 
issue is not further pursued here. The attestor sends the attestation value parts a, e, v" to the 
platform together with the attester determined attribute values w, z. 
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When the platform wants to prove attestation to a verifier, i.e., the verification computer 40, 
that knows the attribute values x and z, it proceeds as follows: It first chooses a random integer 
u and computes 

Tj =a - h u mod n 

5 and sends Tj as part of user attestation-signature value DAA' to the verification computer 40, 
hereafter called verifier. Then it receives a first signature value T'j from the TPM and 
computes an intermediary user attestation-signature value 

T = Ti • cT • h reu -R 3 ' 3 • R 4 14 mod n, 
where re, reu, t3, and t4 are random integers and the R 3 and R 4 are the base values that 

10 correspond to the attributes that remain anonymous, i.e., hidden from the verifier. If the 
platform wants to hide other attribute values, it should use the corresponding bases instead of 
R 3 and R4 (and corresponding random integer exponents instead of t3 and t4) in the 
computation of T f, h The platform then uses T ,y j and some other values as input to a hash 
function to derive the second signature value C\ as indicated with step 202 in Fig. 3. The 

15 platform sends C to the TPM and receives the security module attestation values DAA that 
comprises the values G, sf0\ sfl\ sv\ The platform augments xhese security module 
attestation with at least the values sy 9 = t3 +G • y, sw ' = t4 +G • w, se '= re + G • e } and seu ' 
= reu + G-e-u and sends the resulting list of values as user attestation-signature value DAA' 
to the verifier. 

20 Verifying such a received user attestation-signature value DAA 5 comprises computing by the 

verifier an intermediary user attestation-signature verification value 

T'"i = (T'i/(R 2 X -Rs)) G -r' -R 0 sJ0 -R^' .Tj se ' +G ' L -K seu '-R 3 »'.R 4 M "' mod«, 

where L is a security parameter, and using T'"i in the input to the hash function to derive a 

first user attestation-signature verification value G\ and verifying whether G' equals value G 
25 contained in the user attestation-signature value DAA'. As G is part of the security module 

attestation value DAA that is part of the user attestation-signature value DAA' it is also part of 

the user attestation-signature value DAA'. 

Any disclosed embodiment may be combined with one or several of the other embodiments 
30 shown and/or described. This is also possible for one or more features of the embodiments. 

The present invention can be realized in hardware, software, or a combination of hardware and 
software. Any kind of computer system - or other apparatus adapted for carrying out the 
method described herein - is suited. A typical combination of hardware and software could be 
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a general purpose computer system with a computer program that, when being loaded and 
executed, controls the computer system such that it carries out the methods described herein. 
The present invention can also be embedded in a computer program product, which comprises 
all the features enabling the implementation of the methods described herein, and which - 
5 when loaded in a computer system - is able to carry out these methods. 

Computer program means or computer program in the present context mean any expression, in 
any language, code or notation, of a set of instructions intended to cause a system having an 
information processing capability to perform a particular function either directly or after either 
or both of the following a) conversion to another language, code or notation; b) reproduction 
10 in a different material form. 
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CLAIMS 

1. A method for generating a user attestation-signature value (DAA') for use with a 
verification computer (40), the user attestation-signature value (DAA') corresponding to at 
5 least one attribute (A, B, C, D), each with an attribute value (w, x, y, z), none, one, or more of 
the attribute values (w, y) remaining anonymous for transactions performable by a user device 
(20) having a security module (22) with the verification computer (40), the method comprising 
the steps of: 

- providing a user public key (PKuc) and a proof value that demonstrates that the user public 
10 key (PKuc) was validly derived from a module public key (PK T pm) of the security module 

(22); 

- receiving from an attester computer (30) 

(I) an attestation value (cert) having the at least one attribute (A, B, C, D) with its 
attribute value (w, x, y, z), none, one or more of the attribute values (x, y) remaining 

1 5 unknown to the attester computer (30), 

the attestation value (cert) being derived from an attester secret key (SK A c), a 
user public key (PKuc), and none, one, or more attester determined attribute values (w, 
z), 

the user public key (PKuc) inherently comprising none, one, or more user 
20 determined attribute values (x, y), and 

(II) at least one of the attester determined attribute values (w, z); and 

- deriving the user attestation-signature value (DAA') from the attestation value (cert) and a 
security module attestation value (DAA) provided by the security module (22), 

wherein it is verifiable whether or not (i) the user attestation-signature value (DAA') was 
25 validly derived from the security module attestation value (DAA) and the attestation value 
(cert), and that (ii) the attestation value (cert) is associated with a subset (B, D) of at least one 
attribute, each attribute in the subset (B, D) having a revealed attribute value (x, z). 
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2. The method according to claim 1, wherein the step of deriving the user attestation- 
signature value (DAA') further comprises the steps of: 

receiving from the security module (22) a first security module attestation value (T'i); 

deriving an intermediate user attestation-signature value (CO from the first security module 
5 attestation value (7"/) under use of an attester public key (PK A c) and a hash function; 

providing the intermediate user attestation-signature value (CO to the security module (22); 

receiving from the security module (22) a part of the user attestation-signature value (DAA); 
and 

calculating by the user device (20) further parts of the user attestation-signature value (DAA') 
10 using none, one, or more of the attribute values (w, y), the received part of the user attestation- 
signature value (DAA), the user public key (PKuc), and the attester public key (PK A c). 

3. The method according to claims 1 and 2, wherein the user public key (PK UC ) is derived 
from the module public key (PK T pm) by using the attester public key (PK A c) and the one or 
more of the attribute values (x, y). 

15 4. The method according to any of the claims 1 to 3, wherein the user device (20) provides 
encryptions under a trusted third party's public key of one or more of the attribute values (w, 
y) that remain unknown to the verification computer (40). 

5. A method for issuing an attestation value (cert) for the generation of a user attestation- 
20 signature value (DAA') corresponding to at least one attribute (A, B, C, D), each with an 
attribute value (w, x, y, z), none, one, or more of the attribute values (w, y) remaining 
anonymous for transactions performable by a user device (20) having a security module (22) 
with an attester computer (30), the method comprising the steps of: 

- receiving from the user device (20) a user public key (PKuc) that inherently comprises none, 
25 one, or more user determined attribute values (x, y) invisible to the attester computer (30) and 
a proof value demonstrating that the user public key (PKuc) was validly derived from a 
module public key (PKtpm) of the security module (22); 



CH920030067US1 



- 18- 



- issuing the attestation value (cert) based on an attester secret key (SK A c) 5 the received user 
public key (PKuc), and none, one, or more attester determined attribute values (w, z); and 

- providing the attestation value (cert) to the user device (20), 

wherein the user attestation-signature value (DAA') is derivable by the user device (20) from 
5 the attestation value (cert) and a security module attestation value (DAA) provided by the 
security module (22), and it is verifiable whether or not (i) the user attestation-signature value 
(DAA') was validly derived from the security module attestation value (DAA) and the 
attestation value (cert), and that (ii) the attestation value (cert) is associated with a subset (B, 
D) of at least one attribute, each attribute in the subset (B, D) having a revealed attribute value 
10 (x, z). 

6. A method for verifying a user attestation-signature value (DAA') generated from an 
attestation value (cert), the user attestation-signature value (DAA') corresponding to at least 
one attribute (A, B, C, D), each with an attribute value (w, x, y, z), none, one or more of the 
15 attribute values (w, y) remaining anonymous for transactions performable with a user device 
(20) having a security module (22), the method comprising the steps of: 

- receiving from the user device (20) the user attestation-signature value (DAA'); and 

- verifying whether or not (i) the user attestation-signature value (DAA') was validly derived 
from a security module attestation value (DAA) provided by the security module (22) and an 

20 attestation value (cert), and (ii) the attestation value (cert) is associated with a subset (B, D) of 
at least one attribute, each attribute in the subset (B, D) having a revealed attribute value (x, 

z), 

the attestation value (cert) being derived from an attester secret key (SK A c), a 
user public key (PKuc), and at least one attribute value (w, z) that remains anonymous, 

25 the user public key (PKuc) inherently comprising a user determined attribute 

value (x, y). 



30 



CH920030067US1 



- 19- 



7. Method according to claim 6, wherein the step of verifying further comprises 

computing a first user attestation-signature verification value (G*) by using the user 
attestation-signature value (DAA 5 ), the attester public key (PK A c), and the revealed attribute 
values (x, z); and 

5 checking whether or not the first user attestation-signature verification value (G is comprised 
in the user attestation-signature value (DAA 5 ). 

8. A computer program element comprising program code means for performing the method 
of any one of the claims 1 to 7 when said program is run on a computer. 

9. A computer program product stored on a computer usable medium, comprising computer 
10 readable program means for causing a computer to perform the method according to any one 

of the claims 1 to 7. 

10. A system for using a user attestation-signature value (DAA') that corresponds to at least 
one attribute (A, B, C, D), each with an attribute value (w, x, y, z), none, one, or more of the 

15 attribute values (x, y) remaining anonymous for transactions, the system comprising: 

a user device (20) having a security module (22) that provides a module public key (PKtpm) 
and a security module attestation value (DAA), the user device (20) providing a user public 
key (PKuc) that inherently comprises none, one, or more user determined attribute values (x, 
y) and a proof value demonstrating that the user public key (PKuc) is validly derived from the 
20 module public key (PKtpm) of the security module (22); 

an attester computer (30) that provides none, one, or more attester determined attribute values 
(w, z) and an attestation value (cert) that bases on an attester secret key (SK A c)> the user 
public key (PK UC ), and the none, one, or more attester determined attribute values (w, z); and 

a verification computer (40) for verifying whether or not (i) the user attestation-signature 
25 value (DAA') was validly derived from the security module attestation value (DAA) provided 
by the security module (22) and the attestation value (cert), and (ii) the attestation value (cert) 
is associated with a subset (B, D) of at least one attribute, each attribute in the subset (B, D) 
having a revealed attribute value (x, z). 



* * * 
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ABSTRACT 

The present invention discloses a method for generating and verifying a user attestation- 
signature value (DAA') and issuing an attestation value (cert) for the generation of the user 
attestation-signature value (DAA'). Further, the invention is related to a system for using a 
5 user attestation-signature value (DAA') that corresponds to at least one attribute (A, B, C, D), 
each with an attribute value (w, x, y, z), none, one or more of the attribute values (x, y) 
remaining anonymous for transactions, the system comprising: a user device (20) having a 
security module (22) that provides a module public key (PK T pm) and a security module 
attestation value (DAA), the user device (20) providing a user public key (PKuc) that 

10 inherently comprises none, one, or more user determined attribute value (x, y) and a proof 
value demonstrating that the user public key (PKuc) is validly derived from the module public 
key (PKtpm) of the security module (22); an attester computer (30) that provides none, one, or 
more attester determined attribute value (w, z) and an attestation value (cert) that bases on an 
attester secret key (SK A c), the user public key (PK UC ), and an anonymous attribute value (w, 

15 z); and a verification computer (40) for verifying whether or not (i) the user attestation- 
signature value (DAA') was validly derived from the security module attestation value (DAA) 
provided by the security module (22) and the attestation value (cert), and (ii) the attestation 
value (cert) is associated with a subset (B, D) of at least one attribute, each attribute in the 
subset (B, D) having a revealed attribute value (x, z). 
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